home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Tech Arsenal 1
/
Tech Arsenal (Arsenal Computer).ISO
/
tek-05
/
lanmodm1.zip
/
TESTNET.DOC
< prev
next >
Wrap
Text File
|
1989-11-15
|
15KB
|
397 lines
TESTNET
Utility for Testing NetBIOS Networks
November 13, 1989
CROSS Information Company
Forward.
Several NetBIOS networks are not very stable and do not
provide a correct NetBIOS emulation. This utility will allow
one to test the network to verify that MCOM, UCOM, and
NETDEV will operate correctly within the network environ-
ment. Using this utility, one can simulate modem I/O over-
night to verify that the network will not "hang up" on the
procedure and that the systems involved will not crash.
Using TESTNET.
Find some workstation on your system that has a communica-
tions adapter port (COM port). You must use a COM port even
though you normally intend to use internal modems. Verify
that the COM port operates correctly by using any ordinary
"smart-terminal" program to access the port. You can do this
by connecting a lead between the RS-232C terminals 2 and 3.
This connects the transmit and receive leads together. When
you type something on the keyboard, it should immediately
echo on the screen. If your "smart-terminal" program does
not echo characters, it probably means that the IRQ (inter-
rupt request) lines are not enabled on the communications
adapter card. Verify that COM1 uses IRQ4 and COM2 use IRQ3.
After you have your communications adapter port operating
correctly, leave the jumper between terminals 2 and 3 of the
RS-232C connector and then load MCOM on the workstation.
Using any other workstation on your system, execute TESTNET.
The program should find the "COMM01" device and begin to do
I/O with the MCOM device-driver.
╔═════════════════════════════════════════════════╗
║ TESTNET NetBIOS Network Testing Utility V1.01 ║
║ Copyright (c) 1989 Cross Information Company ║░░░
║ All rights reserved worldwide. Ser 12345 ║░░░
║ Phone (303) 444-7799 FAX (303) 444-4687 ║░░░
║ ║░░░
║ Check network : Okay ║░░░
║ Add name : Okay ║░░░
║ Call name : Okay ║░░░
║ Send data : Okay ║░░░
║ Receive data : Okay ║░░░
║ Check data : Okay ║░░░
║ Send datagram : Okay ║░░░
║ Recv datagram : Okay ║░░░
║ Last error : ║░░░
║ Total errors : 0 ║░░░
║ Total data : 12,799,872 ║░░░
║ Hang up : Okay ║░░░
║ Delete name : Okay ║░░░
╟─────────────────────────────────────────────────╢░░░
║ Re:0000 Ab:004A Co:004F Tx:0FE1291A Rx:0FE11A9B ║░░░
╚═════════════════════════════════════════════════╝░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
- 1 -
TESTNET Page 2
You can also force a specifc device-driver to be called. You
put it's name on the command-line:
TESTNET COMM01 (Calls device COMM01)
TESTNET COMM02 (Calls device COMM02)
The following errors can be returned by TESTNET:
Bad local session number:
An error occurred within NetBIOS that forced the
termination of a session. No such information was reported
to TESTNET by NetBIOS so the very first indication that a
session had been aborted was when NetBIOS refused to accept
any more commands from the local session number.
Can't cancel command:
An attempt was made to cancel a command that had
either already completed or was not allowed to be canceled.
Because TESTNET only cancels one command (the CALL, if
COMM01 is busy), and since the cancel is legal, If you get
this error, your NetBIOS is returning errors not intended
for TESTNET.
Can't find name:
A CALL was made to a named device but there was no
response from the device. Either the device does not exist
or it was busy. This is normal if you don't have the MCOM
driver installed on a net-station somewhere on the local
network.
Command canceled:
A CANCEL command was executed successfully. This
should not appear because TESTNET does not issue any CANCEL
commands after a session has been established.
Command not canceled:
A CANCEL command failed to execute properly. TESTNET
does not issue any cancel commands after a session has been
established.
Command timed out:
A timeout on a RECEIVE or SEND command occurred. If a
timeout occurs during a send, the session is aborted. Time-
outs during receive are normal if there are no data being
received.
Data error:
The data received were not exactly the same as the
data sent.
Duplicate name:
- 2 -
TESTNET Page 3
An attempt was made to ADD NAME when the name was
already in use. Since TESTNET always uses a new unique-name
obtained by converting the system timer-tick into a hexa-
decimal character string, no duplicate names are possible
unless more than one copy of TESTNET is executing on the
network at one time.
Illegal buffer length:
The length of either an output or input buffer was too
long for the command. Since TESTNET always uses the correct
buffer-length which is fixed, not a variable, this error
should never occur.
Illegal name-number:
The session was aborted. The name-number no longer
exists. Something caused the session to be aborted. The fact
that the session had been aborted was not transmitted to
TESTNET so it continued to attempt to communicate with the
MCOM driver. The result was this error-code being returned.
A properly designed NetBIOS would inform a session that
communication has been lost so this error would never occur.
Incompatible remote device
Some hardware on the network is not responding cor-
rectly when addressed. This can be caused by noise on the
network.
Interface busy:
A SEND or RECEIVE command encountered a very busy
network. The commands will be retried.
Invalid command:
Some data-corruption has occurred, destroying the
network control-block. This is usually caused by a stack
overflow. Entering STACKS=15,255 in the CONFIG.SYS file may
help.
Invalid NCB_LANA_NUM:
Two NetBIOS programs are resident in memory. The wrong
one is being addressed. Check your network configuration.
Local session table full:
Two many sessions have already been started. There is
no more room. Reconfigure the network with more sessions
defined. This can also happen when NetBIOS pretends to
delete a name from the local name-table while in fact the
name remains, using a necessary slot.
Locator not responding:
The master station (if any) has gone off-line. If you
don't have a master-station the error-code probably means
that the CALLed name can't be located.
- 3 -
TESTNET Page 4
Message incomplete:
Data during a RECEIVE has been truncated because of a
buffer overflow. This can happen if the network is very busy
and the data-buffer length in the network configuration was
not correctly chosen. The buffer length is normally a
multiple of 1k (1024 bytes).
Name conflict detected:
An attempt was made to ADD NAME to the local session
table when the name was in use somewhere else on the net-
work. Since TESTNET guarantees a unique name, this should
never happen unless TESTNET is executing somewhere else on
the network.
Name de-registered
An attempt was name to DELETE NAME from the local
session table while a command was outstanding. When the
command completes, the same should be deleted. Experience
shows that the name will never be deleted and you will have
lost a slot in the name-table.
Name deleted:
A CALL or HANGUP command was made to a name that was
already deleted. This could happen if a net-station has gone
off-line forcing a session to be terminated.
Name is in use:
An attempt was made to ADD NAME to the local session
table when the name is in use locally. Since TESTNET
guarantees a unique name, this should never happen unless
TESTNET is executing somewhere else on the network.
Name not found:
The CALLed name was not present probably because MCOM
was not loaded on a net-station.
Name table full:
No more slots are available in the local session
table. Reconfigure the network and then re-boot.
NetBIOS not active:
NetBIOS was not loaded or not responding.
No resource available:
Too many TSRs are using resources that are necessary
for the network to operate properly. Notice than some pro-
grams take-over the system's timer-interrupt and therefore
don't allow the network software to get any CPU time. Other
programs actually destroy any interrupt vectors that exist.
Such programs can't be used in a networking environment. To
find such programs, attempt to operate with no TSRs on the
- 4 -
TESTNET Page 5
net-station. Add each TSR until you find the one that des-
troys your system.
Program is corrupt!
The program file was damaged or changed. Obtain a new
copy from the distribution disk. If the program is altered
in any way this message will appear.
Reserved name specified:
Data corruption occurred causing the presence of
reserved characters "*" in the name-field.
Session closed:
An error occurred which forced the session to be
aborted.
Session ended abnormally:
An error occurred which forced the session to be
aborted. This usually occurs when the net-station executing
MCOM is rebooted when MCOM is in use.
Session OPEN rejected:
The CALLed name was found, but was busy.
Stack overflow!
There are too many TSRs using the user's stack during
interrupts. This causes the user's stack to grow too large.
Too many commands:
The NetBIOS in use was unable to queue more than one
command at a time. This is a very poor NetBIOS emulation.
Undefined error:
Something is getting corrupt which caused NetBIOS to
return an error-code that is undefined. This can be caused
by a stack overflow or a TSR that uses memory that doesn't
belong to it.
The status line on the bottom shows the adapter status from
the remote net-station (the one you are communicating with).
Re:0000 Ab:004A Co:004F Tx:0FE1291A Rx:0FE11A9B
| | | | |_ packets received
| | | |_____________ packets transmitted
| | |_____________________ collisions
| |_____________________________ datagram aborts
|_____________________________________ retransmits.
All numbers are hexadecimal.
Running the program.
You can execute TESTNET overnight to see if there will be
any problems with aborted sessions. If you use UCOM to set
- 5 -
TESTNET Page 6
the baud-rate of the UART, you can send many millions of
bytes in an 8 hour period. At high baud-rates like 9600
baud, there may be a few data-errors, about one error for
every 64k of data. At low baud-rates, there won't be any
errors on a properly operating network. The data errors that
can occur result from missed hardware interrupts, not data-
corruption. If you have a fast machine or are using NetBIOS
software that does not disable interrupts for a long period
of time, the error-rate will be very low. Connecting a COM
port with hardware loop-back as is done for this test is a
worst-case situation because a byte is sent during an
interrupt-service routine then immediately received, gener-
ating another interrupt.
- finis -
- 6 -